Attribute mapping for PIV and PIV-I systems

3.4 Attribute mapping for PIV and PIV-I systems

For PIV systems, you must set up the attributes of the PIV certificate policies to have specific Dynamic mappings.

The following tables provide an example configuration for PIV cards.

Note: The order of the attributes may be different on your system; it depends on how the CA is configured.

Important: The PIV Card Authentication certificate policy must not contain a mapping for Email.

3.4.1 Attribute configuration

When setting up your certificate policy attributes, you must consider the following:

When you add a new certificate policy (Base Certificate Template – BCT) within the Digicert management system, by default a Common Name (CN) field is included. Within MyID, this appears in the attribute mapping screen as two fields, mail firstName and mail lastName. You are recommended to delete the default Common Name (CN) field and manually add a new field with the same properties; in MyID, this will appear in the attribute mapping screen as a single common name field, which you can map dynamically to the Common Name field in MyID.
It is expected that you are using the Common Name field, but depending on your system deployment you may need to add fixed values for the Country and Organization codes. Set the order to be Country > Organization > Common Name. Contact your Digicert representative for more information.
MyID includes as search elements all attributes that may be mandatory or recommended. You are recommended to map all attributes that are listed as searchable. If you do not map an attribute, and MPKI considers it mandatory, the certificate issuance will fail. For example, Digicert recommends that you include attributes that refer to the email address, even if they are not part of the certificate data, to allow searches in PKI manager.

3.4.2 Publishing policies

You are recommended to set the jurisdiction to allow the user to decide whether policies should be published, rather than setting the jurisdiction to Always Publish or Never Publish. The PIV signing and encryption certificates should be published, while the PIV authentication certificates should not be published.

The publish flag attribute appears if the jurisdiction is set to allow the user to decide whether the individual policies are published; The attribute must be set to Static, and can contain one of the following:

Yes – the policy is published.
No – the policy is not published.

The case is not important. If you use a value other than Yes or No, an error similar to one of the following will occur:

<Parameters>
    <Status>-6</Status>
    <CAType>SymantecMPKI</CAType>
    <Message>Error found in SendRequest: Unable to cast object of type 'Symantec.Cert.Policy.PublishCert' to type 'System.String'.</Message>
</Parameters>

or:

<Parameters>
    <Status>-6</Status>
    <CAType>SymantecMPKI</CAType>
    <Message>Error found in SendRequest: cACertPublishNameValuePair must be yes or no, not clientProvided</Message></Parameters>

or:

<Parameters>
    <Status>-6</Status>
    <CAType>SymantecMPKI</CAType>
    <Message>Error found in SendRequest: Must specify valid information for parsing in the string.</Message></Parameters>

Note: Using a value of 1 or 0 will not generate an error; however, as 0 is equivalent to Yes and 1 is equivalent to No, to prevent confusion, you are recommended to use Yes and No only.

3.4.3 Attribute tables

Note: The extended attribute configuration file contains an entry for seat ID. You are recommended to map this attribute to Email. See section 3.3.1, Setting up the additional attributes.

The following tables show the recommended options for attribute mapping.

ManagedPKI KeyEscrow DualKey Encryption
Attribute	Value
mail email	Email
common name	Common Name
state	Not Required
country	Not Required
org unit	Organisational Unit
mailStop	Not Required
employeeID	EmployeeID
locality	Not Required
jobTitle	Not Required
corp company	Applicant Group
publish flag (Static)	No

ManagedPKI KeyEscrow DualKey Signing
Attribute	Value
mail email	Email
common name	Common Name
state	Not Required
country	Not Required
org unit	Organisational Unit
mailStop	Not Required
employeeID	EmployeeID
locality	Not Required
jobTitle	Not Required
corp company	Applicant Group
publish flag (Static)	No

ManagedPKI PIV Account Signer
Attribute	Value
common name	Common Name
publish flag (Static)	No

ManagedPKI PIV Authentication
Attribute	Value
common name	Common Name
FASC-N	FASC-N (Hex)
UserPrincipalName	User Principal Name
Email	Not Required
UUID	UUID (ASCII)
NACI Check	NACI Status
publish flag (Static)	No

ManagedPKI PIV Card
Attribute	Value
fascn printable	FASC-N (ASCII)
FASC-N	FASC-N (Hex)
UserPrincipalName	Not Required
Email	Not Required
UUID	UUID (ASCII)
NACI Check	NACI Status
publish flag (Static)	No

ManagedPKI PIV EndUser Encryption
Attribute	Value
common name	Common Name
mail email	Email
publish flag (Static)	Yes

ManagedPKI PIV EndUser Signing
Attribute	Value
common name	Common Name
mail email	Email
publish flag (Static)	Yes

3.4.4 PIV-I systems

The FASC-N mapping is required for standard PIV cards, but is not permitted for PIV-I cards. The Printable FASC-N mapping is set to FASC-N (ASCII) for PIV cards, and UUID (ASCII) for PIV-I cards. NACI is not required for PIV-I.

For example, for a PIV-I system, the following certificate policies would need to be different from the example for a PIV system above:

ManagedPKI PIV Authentication
Attribute	Value
common name	Common Name
FASC-N	Not Required
UserPrincipalName	User Principal Name
Email	Not Required
UUID	UUID (ASCII)
NACI Check	Not Required
publish flag (Static)	No

ManagedPKI PIV Card
Attribute	Value
fascn printable	UUID (ASCII)
FASC-N	Not Required
UserPrincipalName	Not Required
Email	Not Required
UUID	UUID (ASCII)
NACI Check	Not Required
publish flag (Static)	No